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The University of Houston-Clear Lake established the Research Institute for 
Computing and Information Systems (RICIS) in 1986 to encourage the NASA 
Johnson Space Center (JSC) and local Industry to actively support research 
in the computing and information sciences. As part of this endeavor, UHCL 
proposed a partnership with JSC to jointly define and manage an integrated 
program of research in advanced data processing technology needed for JSC’s 
main missions, Including administrative, engineering and science responsi- 
bilities. JSC agreed and entered into a continuing cooperative agreement 
with UHCL beginning in May 1986, to jointly plan and execute such research 
through RICIS, Additionally, under Cooperative Agreement NCC 9-16, 
computing and educationaTTacfiities are shared by the two institutions to 
conduct the research. 

The UHCL/RICIS mission is to conduct, coordinate, and disseminate research 
and professional level education in computing and information systems to 
serve the needs of the government, industry, community and academia. 
RICIS combines resources of UHCL and its gateway affiliates to research and 
develop materials, prototypes and publications on topics of mutual interest 
to its sponsors and researchers. Within UHCL, the mission is being 
implemented through interdisciplinary involvement of faculty and students 
from each of the four schools: Business and Public Administration, Educa- 
tion, Human Sciences and Humanities, and Natural and Applied Sciences, 
RICIS also collaborates with industry in a companion program. This program 
is focused on serving the research and advanced development needs of 
Industry. 

Moreover, UHCL established relationships. with other universities and re- 
search organizations, having common research interests, to provide addi- 
tional sources of expertise to conduct needed research. For example, UHCL 
has entered into a special partnership with Texas A&M University to help 
oversee RICIS research and education programs, while other research 
organizations are involved via the ‘gateway 1 ’ concept 

A major role of RICIS then is to find the best match of sponsors, researchers 
and research objectives to advance knowledge In the compu ting and informa- 
tion sciences. "RICIS, working jointly with its sponsors, advises on research 
needs, recommends principals for conducting the research, provides tech- 
nical and administrative support to coordinate the research and Integrates 
technical results Into the goals of UHCL, NASA/JSC and industry. 
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1 Introduction 

This report presents a brief example of the use of formal methods techniques 
in the specification of a software system. The report is part of a larger effort 
targetted at defining a formal methods pilot project for NASA. This report’s 
purpose is to present one possible application domain that may be used to 
demonstrate the effective use of formal methods techniques within the NASA 
environment. It is not intended to provide a tutorial on either formal methods 
techniques or the application being addressed. It should, however, provide 
an indication that the application being considered is suitable for a formal 
methods by showing how such a task may be started. 

The particular system being addressed is the Structured File Services 
(SFS), which is a part of the Data Storage and Retrieval Subsystem (DSAR), 
which in turn is part of the Data Management System (DMS) onboard 
Spacestation Freedom [1]. This is a software system that is currently un- 
der development for NASA. 



An informal mathematical development is presented in the section 2. Sec- 
tion 3 contains the same development using Penelope [23], an Ada specifi- 
cation and verification system. The complete text of the English version 
Software Requirements Specification (SRS) is reproduced in Appendix A. 


2 An Informal Mathematical Model 

In beginning the task of formally describing a computer system, a specifier 
of the system will initially develop an informal mathematical model. In de- 
veloping the informal model the specifier will naturally use common intuitive 
notions from mathematics. Set theory and function theory will be used to 
describe the behavior of the SFS. Describing the system in terms of its state 
and how the system may transition from one state to another is also a com- 
mon technique that we will use. While the use of these techniques will be 
informal and ad hoc, the next section will use a formal notation for describing 
the SFS that reflects the developments in this section. 

We begin by examining the processing requirements placed on the SFS. 
These are captured in a series of shalls written in plain english text. 

Shall 1 SFS shall (1) create a structured file upon request from the software 

user. 

The first shall introduces several terms. To model these terms, we intro- 
duce several definitions. 

• The set USER is the set of SFS users. 

• The set SFS-FILE is the set of all SFS files. 

• The set FILE-NAME is the set of SFS file names. 

Now a function, create.file, can be defined. This function, when supplied 
a user and a filename, returns a valid SFS file. The domain and range of the 
function are defined as 

• create _ file : USER x FILE-NAME SFS-FILE. 


As additional elements of the SFS model are defined, the behavior of the 
function create-file may then be defined. 

The SFS files are part of the state of the SFS system. As the system 
executes and user requests are serviced, this state will change. To describe 
these changes in state, various components, as well as the overall state, are 
given names. We call the entire state, sfsstate. The SFS files are called 
sfs-files and are a component of sfsstate. Also the SFS file names are 
sf S-f ile-names and are also a component of the state. 

The operation of creating a file upon user request will certainly change 
the state of the SFS. Before defining this change in state, it is worthwhile to 
note that the SFS, later in the SRS, specifies other user services that may be 
requested. These correspond to the input DDFS.SFS specified in the SRS as 
input to the SFS. Let DDFSSFS = {create, open, read, write, delete, dir) 
be this set of requests. The set DDFSSFS captures the fact that these 
various requests exist, but does not indicate how these requests may effect 
the system. 

Now, for some DDFS to SFS request, create £ DDFSSFS, we can 
specify some change in the sfsstate. That is, for some, user £ USER, and 
file.name £ FI LEJV AME, 

• a new file £ SFS-FILE should be created, 

• the state component sfs-files should be updated, and 

• the state component sf s.f iles-names should be updated. 

Additional, elements of the model must be defined in order to complete 
the definition of the response to a create £ DDFSSFS request. We con- 
tinue by examining shall number 2 in the SRS. 

Shall 2 SFS shall (2) establish a dictionary describing the structured file so 
that it can manage the updating of the file. 

It seems clear that an SFS dictionary of some sort should be included as 
part of the state, call it sfs-dict. This dictionary will provide information 
about SFS files, so we index it by SFS file names. When looking up the entry 
for a particular file, by name, we would expect in return an entry for that 
file which describes various aspects of the lile. A function 


• lookup : SFS-DICT x FILE-NAME -> DICT .ENTRY 


serves this purpose. 

When files change, it may be necessary to modify their dictionary entries. 
A function update is used to update dictionary entries. Given a dictionary 
and a new entry for a particular file, a new dictionary, appropriately updated 
will be returned. The domain and range for this function is given as 
update : SFS-DICT x FILE-NAME x DICT -ENTRY - SFS-DICT 

The relationship between lookup and update is that lookup will always 
return the appropriate entry in an updated dictionary. This realtionship is 
formally defined in the next section. 

Continuing with the shalls from the SRS. 

Shall 3 The dictionary shall (3) contain the number of records in the file, the 
record size, the record structure, the archive threshhold (prescribed percent- 
age capacity threshhold for archiving the file), an archive/circular indicator 
(indicating whether the file should be archived or overwritten), and access in- 
formation (user identification, password, read onlt access, write access, delete 
access, archive rights, etc ). 

This shall defines various elements of a dictionary entry. The following 
functions on a dictionary entry are introduced. 

• nrec : DICT -ENTRY -+ jV 

• recsize : DICT -ENTRY -♦ Af 

• recstruct : DICT -ENTRY — > A! 

• archive : DICT -ENT RY — » B 

• access : DICT -ENTRY - ACCESS-INFO 

where Af = {0, 1,2,...} and B = {true, false } 

An element of the set ACCESS-! NFO is a set of access rights granted 
to users for a particular file. These access rights are defined by the set 
ACCESS-RIGHTS = {read, write, delete, execute}. So, we may define 
ACCESS-INFO as the set of all subsets of ACCESS-RIGHTS, or equiv- 
alently, ACCESS-INFO = V{ACC ESS-RIGHTS). 
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To this point, not much more than the naming of various components of 
the model has taken place. In addition to naming components, we have also 
indicated some structure and nature of each of the components. As develop- 
ment of the model proceeds this structure would be more fully defined and 
eventually yield a complete mathematical model of the intended structure of 
the entire system. The structure would then be suitable for various analysis, 
refinement and documentation purposes. This short example only serves to 
give a flavor for a style of development possible. 

Given the start of an informal mathematical model, a system designer 
may decide to record his design formally. The next section addresses the 
same issues as this section, only in the framework of a formal mathematical 
notation. 


3 Developing a Formal Mathematical Model 

The previous section developed a model of the SFS using a relatively informal 
style of mathematical presentation based on commonly understood mathe- 
matical notions of set and function theory. This section addresses essentially 
the same portions of the specification but uses a formal mathematical nota- 
tion. The notation used is taken from the Penelope Ada specification and 
verification system developed at Odyssey Research Associates [23]. It is a 
system based on the Larch style of specification and is similar in its mathe- 
matical style to systems such as EHDM, LSL, PVS. That is, its specifications 
are algebraic in nature. Penelope has the additional ability to directly address 
issues of Ada code specification and verification. The details of Penelope are 
not presented here and the specification is presented simply as a demonstra- 
tion of the feasibility of applying mechanical means to the specification and 
verification of systems such as the DSAR SFS. 

In the following treatment a basic style of algebraic specification is used 
to capture the meaning of statements in the SRS. English text provides an 
informal description of each component of the specification. In the following 
treatment the Larch construct called a trait is used to encapsulate a particular 
theory. That is, a set of related facts which form a logical structure and from 
which further facts may be deduced. The algebraic form of specification in 
Larch uses sorts and operators to define logical theories. Sorts and collections 
of objects. Operators define functions from sorts into sorts. 



In the previous section, sets were used to describe various aspects of the 
model. The notion of a set needs to be formally defined by introducing 
operators and sorts which capture the usual behavior of sets. In this case, 
empty, and member are alternate notations for the usual notions {} and £, 
respectively. 


< . 



trait Set is 
introduces 
empty: -> Set; 

insert: Element, Set -> Set; 
member: Element, Set -> Bool; 

. additional set operations omitted ...> 
asserts 

Set generated by empty, insert 
Set partitioned by member 
axioms: forall [e: Element, el: Element, s:Set] 
not_member_empty : (not member(e, emptyO)); 
member_insert : (member(e, insert(el, s)) = 

((e=el) or 
member(e, s))); 

. axiomatization of additional set operations omitted ...> 
end axioms; 


Additional set manipulations constructs such as set union and intersec- 
tion may be similarly defined. Basic mathematical notions such as sets, 
sequences, lists, and stacks, would normally be provided in a collection of 
theories gathered in a library and available for use by the specifier. This 
theory of sets is developed in a generalized form and later used (and reused) 
in several s pecia lized forms. 

The following trait defines a general theory of dictionaries that will be 
used subsequently. A dictionary is some object to which the operations 
update and lookup may be applied and in which update and lookup have the 
appropriate relation to each other. In addition, the operation defined may 
be used to check the definedness of a particular index. 


— I trait Dictionary is 

— I introduces 
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— I empty: -> Diet; 

— | update: Index, Ent , Diet -> Diet; 

— I lookup: Index, Diet -> Ent; 

— | defined: Index, Diet -> Bool; 

— I asserts 

— I Diet generated by empty, update 

— I Diet partitioned by lookup 

— I axioms: forall [ i 1 , i2: Index, el, e2:Ent, dl, d2:Dict] 

— I not.defined: (not defined(il, eraptyO)); 

— I defined: (defined(i2, update(il, el, dl)) = 

((il=i2) or 
def ined(i2, dl))); 

— I lookup: (lookup(i2, update(il, el, dl)) 

(if (il=i2) then el else lookup(i2, dl))); 

— I end axioms; 

— I lemmas: forall [il, i2: Index, el, e2:Ent, dl, d2:Dict] 

— I lookup_same : (lookup(il, update(il, el, dl))=el); 

— I proof: 

— ! BY synthesis of FORALL 

— ! BY synthesis of FORALL 

— ! BY synthesis of FORALL 

— ! BY lookup in trait Dictionary 

--! substituting for left 

— ! BY synthesis of TRUE 

— I end lemmas ; 

While this theory is developed in general in terms of Index, Entry, Diet, 
etc. The use of the theory will be in terms of file names and SFS files, as in 
Section 2. In fact, it may eventually be reused in various specialized forms. 

The trait Dictionary not only introduces some new concepts related to 
dictionaries but also contains the proof of a property lookup same which 
says that after updating a dictionary entry, looking it up will return the 
correct entry. Proofs of properties that follow from basic definitions can be 
considered a form of design verification. 

The SRS specifies various items as input to the SFS. One of these is a 
DDFS to SFS message or data item. The DDFS-SFS trait defines the possi- 
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ble DDFS to SFS operations, create, open, read, write, dir . The behavior of 
these operations is not yet defined. 

— | trait DDFS_SFS is 

— I introduces 

— I sort DDFS.SFS is enumeration (create, open, read, write, dir) 

The enumeration construct defines a particular sort and its individual 
elements much as in section 2 we used the set notation, DDFS -SFS = 
{create, open, read, write, delete, dir} to define DDFS-SFS. 

In response to the DDFS to SFS operation a message from the SFS to the 
DDFS is required. The trait SFSJDDFS specifies some messages from the 
SFS to the DDFS in response to the DDFS to SFS operations. Again, the 
enumeration construct is used to define the elements of the sort SFS.DDFS. 

— I trait SFS_DDFS is 

— I introduces 

— I sort SFS_DDFS is enumeration (create.ok, create.error, ...) 

<... more SFS_DDFS message specifications elided ...> 

Access rights to files are granted to users of the SFS. These access rights, 
read, write, and delete, are defined in the next trait. 

— 1 trait AccessRights is 

— I introduces 

— I sort AccessRight is enumeration (read, write, delete) 

Various information, beyond simply access rights, must be maintained for 
files in the system. The trait Accesslnfo defines what this information is and 
how it can be manipulated. The trait Accesslnfo makes use of previously 
defined traits for Sets and AccessRights. 

--| trait Accesslnfo is 

— I includes (AccessRights) 

— I includes (Set) (AccessRight for Element, 

UserAccessRights for Set) 

--| includes (Set) (UserAccessInf o f or Element, 

Accesslnfo for Set) 

— I introduces 

--| sort UserAccessInf o is tuple (User, Password, UserAccessRights) 
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The trait Accesslnfo shows how previously defined concepts can now be 
effectively used to build up more complex theories. In this case, the trait 
AccessRights is included in its original form. Because we would also like 
to manipulate sets of AccessRights, we include the trait Set, renaming the 
general sort Element with the specific sort AccessRights. Similarly, for User- 
Accesslnfo, the trait Set is included. The tuple construct defines the sort 
UserAccessInfo to be a triple, the first element taken from the sort User, the 
second from the sort Password, and the last from the sort UserAccessRights. 

The SFS Dictionary is a specialization of the general theory of dictionaries 
defined in the trait Dictionary. It is specialized to the case where entries 
are file information and the indexes are file names. Additionally, other file 
information operators are defined which describe the types of file information 
being retained in the dictionary. 

— I trait SFS_DICTIONARY is 

— I includes (Dictionary) (Filename for Index, 

Filelnfo for Ent, 

SFS_Dict for Diet) 

— I includes (Accesslnfo) 

— I introduces 

— I rec_count : Filelnfo -> Int; 

— I rec_size: Filelnfo -> Int; 

— I rec_structure : Filelnfo -> RecStruc; 

— I arch_thresh: Filelnfo -> Int; 

— I arch_circ: Filelnfo -> Bool; 

— I access_info: Filelnfo -> Accesslnfo; 

The SFS state information can now be defined by a trait, S F S JST AT E. 
The components of the S FS-State defined in this trait are SFS-Dict and 
SFS-Files. There is a distinguished state called s f s .initial state about 
which the axiom s f s .initial. state. diet, states that “the initial state contains 
an empty dictionary”. In such a way, information about the desired initial 
state of the system and any other states in the system may be recorded. For 
example, the intent of the predicate s fs .valid-state is to specify which states 
in the system are valid. 

— I trait SFS_STATE is 
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includes (SFS.DICTIONARY) 
introduces 

sort SFS_State is tuple (SFS_Dict, SFS_Files); 
sf s_initial_state: -> SFS_State; 
sf s_val id_ st ate : SFS_State -> Bool; 
axioms : 

sf s_ initial _st at e_dict : (sf s_dict (sf s_initial_state() ) = 

empty () ) ; 

definition of sf s_valid_state omitted ...> 
end axioms; 


The SFS state information and the messages to and from SFS and DFSS 
can now be incorporated into the trait SFS which will define the processing 
requirements for SFS. The function sfs.operation when axiomatized will 
define how a particular user can operate on a particular file with a particular 
operation in a given state of the system. The result is the new state of 
the system. The function sf a .result defines the resultant message when the 
operation is attempted. 


< . 


trait SFS is 
includes (SFS_STATE) 
includes (SFS_DDFS) 

includes (DDFS_SFS) (Operation for DDFS_SFS) 
introduces 

sf s_operation : User, Filename, Operation, 

SFS_State -> SFS_State; 
sfs.result: User, Filename, Operation, 

SFS_State -> SFS.DDFS; 

. axioms for operations omitted ...> 


Using the mathematical model developed so far, which culminated in the 
trait SFS, a specification of an Ada package can be written. This specification 
begins to define the actual Ada constructs, types, objects and functions which 
will eventually realize the SFS. 


--| with trait SFS ; 
package SFS is 
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--| based on SFS.State 

type sfs_ filename is private ; 

--| based on Filename; 

type sf s_username is private ; 

-- | based on User; 

type sf s_ddf s_message is private ; 

--| based on SFS_DDFS; 

function sf s_create_f ile(user : in sf s_username ; 

file : in sf s_f ilename) 
return sf s_ddf s_message; 

— I where 

— I Global SFS : IN OUT; 

— I in sf s_valid_state(SFS) ; 

— I out sf s_valid_state(SFS) ; 

— I out (SFS = sf s_operation(user, file, create(),in SFS)); 

— I return sf s_result (user , file, create(),in SFS); 

— I end where; 

<♦,. remaining SFS functions, procedures, objects are omitted ...> 
end SFS ; 

The Ada package SFS has associated with it a state, SFS, which given 
the annotation above, is based on the sort SFS State in the sort SFS. The 
behavior of function and procedure in the package SFS will be partially 
defined in terms of their effect on this state. 

The types introduced are private to the package being defined. That 
is, their actual implementation is not important to the user of the package. 
However, we note that they arc based on elements of the mathematical de- 
scription of the SFS in sort SFS. From this, it is possible to deduce aspects 
of their behavior. 

The single function sf sjct tale-file is also specified in terms of the math- 
ematical objects in the specification. Paraphrased, the specification reads 
something like: “The function sfsxreaie-file modifies the state of package 
SFS. On entry to the function the state of SFS must be valid and on exit the 
new state of SFS must be valid. The new value of the state is defined by the 
sfs-operation function when the desired operation is create and the user is 
returned the value of the sf sjrcsult function .’ 1 
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This package specification may now serve two purposes. 

1. It provides a clear description of the desired program in a manner 
which is independent of the actual code design of the software. That 
is, it is based solely on the mathematical description of the design. A 
designer and developer of the actual code may refer to the mathematical 
description of the objects being coded whenever a question arises as to 
the specification’s intent. 

2. Developed code may be verified against the mathematical description 
of the code to provide a greater assurance in the correctness of the 
developed code. 

4 Conclusions and Recommendations 

This example is meant to show a possible style of specification which may 
be applied to the SFS software component. The formal specification would 
provide clear, unambiguous specifications which would be suitable for various 
kinds of analysis, both mechanical and human. 

The presentation was necessarily short and incomplete. Its intention was 
to provide an insight into the appropriateness of formal methods techniques, 
as well as the suitability of the DMS DSAR function as a target application. 

A formalization of the DSAR requirements appears to be feasible and 
would result in a clear specification of its functionality. The application of 
formal methods techniques to this software system does not seem to be a 
high risk endeavor. Therefore it would seem a likely choice for a pilot project 
in formal methods at NASA. 

The main areas that the formalization would address include: 

• Input, output, and state data format specifications, 

• Functional description of user interfaces to the DSAR, 

• Interaction of functional components of the DSAR. 

The most difficult issues to be addressed in a formalization of the require- 
ments should not be overlooked. 


• There are concurrency and multiprocessing requirements placed on the 
software. An appropriate technique for mathematically describing con- 
currency must be selected or developed. 

• The interface to operating system services must be formalized. This 
would entail formalizing at least a portion of the Ada/OS runtime 
environment. 

Finally, it should be made clear what the intention of the formalization 
effort is: 

• To provide a clear, concise specification of the system that can be used 
by system designers in further developing the system, and to serve as a 
reference point when ambiguities or conflicts arise in the system design 
and implementation. 

• To provide a formal model of the system from which properties of the 
system may be formally verified. In this case, what those properties 
are still needs to be determined. 

• To provide a basis for the formal design and verification of the actual 
implementation of the system. This would entail code verification in 
an effort to increase assurance in the final software product. 

For each of these goals, a formal treatment of the software requirements 
for DSAR will yield a software system with a higher degree of assurance in 
its correctness. 
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A Software Requirements Specification 

The following software requirements specification is taken from the Data 
Management System (DMS) Data Storage and Retrieval (DSAR) Software 
Requirements Specification (SRS). It the the section that addresses processing 
requirements for the Structured File Services (SFS) component of the DSAR. 
It is presented here unedited and in its entirety. 


A.l 4. 1.2. 1.1 INPUTS 


Name 

DDFS-SFS 


DFTSS-SFS 

ST.FILE-SFS 


Description 

The distributed structured file 
request from a DMS service user 
or a directory list request 

Response from an archive request 

Input Structured File 


Source 

DDFS 


DFTSS 
ST. FILE 


A. 2 4.1. 2. 1.2 PROCESSING 

SFS shall (1) create a structured file upon request from the software user. 
SFS shall (2) establish a dictionary describing the structured file so that 
it can manage the updating of the file. The dictionary shall (3) contain the 
number of records in the file, the record size, the record structure, the archive 
threshhold (prescribed percentage capacity threshhold for archiving the file), 
an archive/circular indicator (indicating whether the file should be archived 
or overwritten), and access information (user identification, password, read 
onlt access, write access, delete access, archive rights, etc.). SFS shall (4) 
inform the requestor that the file has been created. 

The SFS shall (5) accept write requests for the structured file. If the file 
size has exceeded the threshhold, SFS shall (6) automatically request that 
the file be transferred to the archive via the DMS File Transfer Service or 
begin overwriting the file file depending on the archive/circular indicator. 
If a file is to be archived, the SFS shall (7) ensure that no structured file 
processing interferes with archiving the file. Then, SFS shall (8) write the 
data to a 2I\B buffer in main memory. When the buffer is full, SFS shall (9) 
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write the contents to the mass storage device (MSD). SFS shall (10) notify 
the requestor of the actions taken. 

SFS shall (11) accept requests to open, close, read, or delete a structured 
file, or provide a directory list. A directory list is a file containing the list 
of files and the attributes of files contained in a designated directory. SFS 
shall (12) provide access to structured files via a key to be: record number, 
time, date, date and time, or a range of dates and/or times. SFS shall (14) 
permit access to individual field(s) within a record. SFS shall (15) provide 
for on-demand read requests. SFS shall (16) provide a locking mechanism to 
protect the integrity of the data. If a read or write request for a locked file 
is received, SFS shall (17) not honor the request and shall (18) inform the 
requestor that the file is locked. 

SFS shall allow multiple concurrent access to centralized structured files. 
SFS shall (20) provide for distributed access to structured file services from 
SDPs and MPACs on core and payload networks. The interface to SFS shall 
(21) be such that the requestor need not know where the structured files are 
located or the detail of the detail of the mechanisms used to perform the 
structured file services. 

For all of the requests described above, SFS shall (22) determine if the 
requestor ha s authorization to access the structured file in the manner re- 
quested. If access is not authorized, the SFS shall (23) deny access and 
inform the requestor of that fact. SFS shall (24) maintain a log of denied 
acesses and report denied access to predesignated MPAC. 

SFS shall (25) accept requests for structured file services from the dis- 
tributed interface for DMS service users. When the service is complete SFS 
shall (26) transmit the requested information or status to the requestor. If 
the service cannot be performed, SFS shall (27) transmit the reasons to the 
requestor. 

SFS shall (28) honor requests for structured file services based on input 
priority level of the requests. SFS shall (29) provide for concurrent, use of 
the files. 

SFS shall (30) maintain a Structured File Dictionary containing a record 
of all structured files using information provided when a structured file is 
created. 

SFS shall (31) use the file services of the OS/Ada RTF CSCI for inter- 
facing to the MSD. SFS shall (32) SFS shall provide for a number of retries 
for reads and writes when I/O errors are encountered. The number of retries 
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will be provided in the detailed design. 

SFS shall (33) transmit to SM a service usage notification for logging 
of SFS activities. SFS shall (24) maintain a log of all errors resulting er- 
rors resulting from structured file requests in an SFS Error Log. SFS shall 
(35) make the information in the error log available to SM on demand or 
periodically. 


A. 3 4. 1.2. 1.2 OUTPUTS 


Name 

SFS-DDFS 


SFS-DFTSS 


Description 

The response from a structured 
file request or a file containing 
a directory list request. 

Request to transfer a structured 
file to the archive 


SFS-ST.FILE Structured File Output 

SFS-NHSDM Health and Status, activity data, 

error log. 


Destination 

DDFS 


DFTSS 

ST. FILE 
SM NHSDM 
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